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METHOD AND SYSTEM FOR RESOURCE RESERVATIONS IN A MULTICASTING 

NETWORK 

5 

BACKGROUND OF THE INVENTION 

1. Technical Field 

10 

The present invention relates to a method for improving 
communications between senders and receivers via a network, such 
as servers, routers, and clients communicating via the Internet 
comprising routers by extending signaling messages of a protocol 
15 used for the network and a communication system operated by the 
method according , to the .invention. 

2 . Background of the Invention 

20 The Resource Reservation Protocol (RSVP) is specified by the 

Internet Engineering Task Force (IETF) and used to provide the 
signaling to enable network resource reservations and 
allocations to provide Integrated Services. In particular, RSVP 
enables Guaranteed Services and Controlled-Load Services. In 

25 this manner it is possible, for example, to obtain a control and 
guarantee of load for network ^resources/components , such as 
network domains, servers, clients, routers, and communication 
links. Resources are reserved or allocated for unidirectional 
data flows. A detailed description of the RSVP can be found in 

30 the article "RSVP and Integrated Services in the Internet: A 
Tutorial" by P. P. White in IEEE communications Magazine, May 
1997, p. 100. 

In RSVP the server sends a PATH-message to the client, 
35 containing a traffic specification (upper and lower bounds of 

bandwidth, delay and jitter) . This message is used to store the 
path state in each node (e.g. router) to route Reservation- 
Request- (RESV) -messages in the reverse direction. On the way of 
the RESV-message to the client, each network checks the traffic 
4 0 specification and possibly filters the requirements according to 
the network capabilities and resource availability (admission 
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control) . The traffic specification is received by the client, 
upon which the client returns a RESV-message to the server to 
reserve the resources between the client and the server. 

5 Since most traffic requiring reservations is delivered to groups 
(e.g. TV), it is natural for the client to make the request for 
a reservation for a flow. This has the added advantage that 
different clients can make heterogeneous requests for capacity 
from the same source. 

10 

The primary roles of the PATH-message are first to install 
reverse routing state in each router of the network along the 
communications path, and second to provide clients with 
information about the traffic characteristics of the sender and 

15 end-to-end (sender-client) communications path to generate 

appropriate reservation/allocation requests. The primary role of 
the RESV-message is to carry reservation/allocation requests to 
routers of the network along the distribution tree between 
clients and senders, wherein the distribution tree can also be a 

20 connection between one server and one client. 

Fig. 1 provides a (simplified) overview of the RSVP signalling 
messages flows and the most important parameters in each of the 
messages . 

25 

The most relevant information in the PATH-message is the TSPEC 
of the sender defining the sender traffic characteristics. 

The ADSPEC is an optional object that the server may include in 
30 its generated PATH-messages in order to provide the clients with 
the characteristics of the end-to-end communications 
path. This information can be used by clients to determine the 
level of reservation required in order to achieve their desired 
end-to-end QoS . The parameters included in the ADSPEC may be 
35 updated at each RSVP-capable router along the path in order to 
present end-to-end values to the clients. Some of the parameters 
are e.g. the minimum path latency, summation of individual link 
latencies, the path bandwidth, and the minimum of individual 
link bandwidths along the path. 
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RSVP supports both unicast and multicast sessions. The flow 
descriptors specify the QoS, which is used by participating 
entities, such as routers, server and clients. Hosts use RSVP to 
5 request a QoS level from the network on behalf of an application 
data stream. Routers use RSVP to deliver QoS requests to other 
routers along the path{s) of the data stream. RSVP is able to 
adapt to changes in routing. 


10 A simplified overview of the operation of the RSVP is given in 
the following. 

Servers characterize outgoing traffic in terms of upper and 
lower bounds of bandwith, delay, and jitter. RSVP sends a PATH- 
g| 15 message from the server that contains this traffic specification 
teji (TSPEC) information to the destination address (unicast or 

ni multicast receivers) . At reception of a PATH-message an RSVP 

ifl capable router creates a PATH-state and stores the last hop 

yi address from the PATH-message and the TSPEC-inf ormation in the 

f- 20 PATH-state. The last hop address is used for the routing of the 
RESV-message afterwards. Additionally, RSVP capable routers may 
h| update the ADSPEC-inf ormation to contain end-to-end relevant 

W parameter values . 

25 To make a resource reservation/allocation, clients send a RESV- 
(reservation request ) -message upstream. In addition to the 
TSPEC, the RESV message includes a request specification (RSPEC) 
that indicates the type of integrated services required and a 
filter specification (FilterSPEC) , that characterizes the data 

30 packets for which the reservation is being made. (e.g. the 

transport protocol and port number) . Together, the RSPEC and 
FilterSPEC represent a flow-descriptor that routers use to 
identify each reservation. 


35 When each RSVP router along the upstream path receives the RESV- 
message, it uses the admission control to authenticate the 
request and allocate the necessary resources. If the request 
cannot be satisfied (due to lack of resources or authorization 
failure) , the router returns an error back to the client. If 


' 030650-079 

Telefonaktiebolaget LM Ericsson (publ) - 4 - 9A-87 517 

P13830 

accepted, the router sends the RESV upstream to the next router. 
When the last router receives the RESV and accepts the request, 
it sends a confirmation message back to the client. There is an 
explicit tear-down process for a reservation when a sender or 
5 receiver ends an RSVP session. 

Token Bucket Metaphor 

RSVP is based on the token bucket metaphor, which turns an 
uneven flow of packets from the user processes inside the host 
10 into an even flow of packets onto the network, smoothing out 

bursts and greatly reducing the chances of congestion. In this 
manner, a controlled load can be provided throughout the 
network. 

15 Token bucket related parameters, which are to be defined for the 
TSPEC-inf ormation, include peak rate of flow (bytes/s) , bucket 
depth (bytes) , token bucket rate (bytes/s) , minimum policed unit 
(bytes) , and maximum datagram size (bytes) . 

RSVP and Integrated Services 

20 RSVP enables so-called Integrated Services, of which there are 
two fundamentally different types: 

Guaranteed Services: A guaranteed service comes as close as 
possible to emulating a dedicated virtual circuit. It provides 
25 firm (mathematically provable) bounds on end-to-end queuing 
delays by combining the parameters from the various network 
elements in a path, in addition to ensuring bandwidth 
availability according to the traffic specification parameter in 
the PATH-message . 

30 

Controlled-Load Services: A controlled-load service is 
equivalent to "best effort service under unloaded conditions". 

Integrated services uses a token-bucket model to characterise 
35 its input /output queuing algorithm. This is, as an example, 
beneficial in case of a variable bit-rate video codec. The 
token-bucket parameters "bucket rate", "bucket depth", and "peak 
rate" are part of the TSPEC- and RSPEC-inf ormation . 
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RSVP provides the highest level of Internet Protocol Quality of 
Service (IP-QoS) available. It allows an application to request 
QoS with a high level of granularity and with the best 
5 guarantees of service delivery possible. However, the price for 
this is the complexity and overhead, and thus is overkill for 
many applications. 

Multicasting 

10 Multicast is the efficient transmission of an Internet Protocol 
(IP) datagram to a set of zero or more hosts identified by a 
single IP destination address. 

IP multicast efficiently supports one-to-many and many-to-many 
15 transmission by enabling sources to send a single copy of a 
message to multiple recipients (indirectly identified by a 
single IP class-D multicast address) who explicitly want to 
receive the information. This mechanism is far more efficient 
than sending multiple messages to each recipient simultaneously 
2 0 or broadcasting the message to all nodes on the network. IP 

multicasting is a natural solution for multi-party conferencing 
because of the efficiency of the data distribution trees 
(spanning trees) , with data being replicated in the network at 
appropriate points rather than in end-systems. 

25 

Multicasting is based on a series of specific protocols that 
"ride on top" of the existing ones to efficiently distribute 
data to all interested parties. With IP multicast clients do not 
need to know who or where the servers are to receive traffic 
30 from them. Servers never need to know who the clients are. 
Neither servers nor clients need to care about the network 
topology as the network optimizes delivery. 

Multicast is a receiver-based concept. Receivers join a 
35 particular multicast session group by informing the multicast 

router on their subnetwork (Internet Group Management Protocol, 
IGMP) and traffic is delivered to all members of that group by 
the network infrastructure. For delivery of a multicast packet 
from the source (sender, server) to the destination nodes on 


^ 030650-079 

Telefonaktiebolaget LM Ericsson (pub 1) - 6 - 9A-87 517 

P13830 

other networks, multicast routers need to exchange the 
information they have gathered from the group membership of the 
hosts directly connected to them. There are many different 
algorithms and protocols to exchange this routing information, 
5 such as Distance Vector Multicast Routing Protocol (DVMRP) , 
Multicast extension to OSPF (MOSPF) , and Protocol Independent 
Multicast (PIM) . Based on the routing information obtained 
through one of these protocols, whenever a multicast packet is 
sent out to a multicast group, multicast routers will decide 
10 whether to forward that packet to their network (s) or not. 

Finally, the leaf router will see if there is any member of that 
particular group on its physically attached networks based on 
the IGMP information and decides whether to forward the packet 
or not. 

15 

If the sender layers its data (e.g. video or audio) stream, 
different receivers can choose to receive different amounts of 
traffic and hence different qualities. To do this the sender 
must code the data (e.g. video data) as a base layer having the 

2 0 lowest quality being acceptable and a number of enhancement 

layers, each of which adds more quality at the expense of more 
bandwidth. With video, these additional layers might increase 
the framerate or increase the spatial resolution of the images 
or both. Each layer is sent to a different multicast group and 

25 receivers thereof can individually decide how many layers to 
subscribe to. 

Fig. 2 shows an IP multicast scenario where a video stream is 
sent to four recipients (i.e. clients 1, 2, 3 and 4). Clients 1 

30 and 2 have joined the group by informing multicast router R2 and 
clients 3 and 4 have done the same with multicast router R3 . 
Client 1 receives a base layer (white packets), e.g. a code 
optimized for wireless environments, whereas client 2 receives 
this base layer and an additional layer (gray packets) for a 

35 better video quality. Clients 3 and 4 receive a different base 
layer (e.g. a wireline codec) . 


To achieve an efficient transmission, a spanning tree is 
constructed, that connects all members of the multicast group. 
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Only one copy of a multicast message will pass over any link in 
the network between the sender (server) and multicast router Rl . 
Copies of the message will be made only where paths diverge at a 
router (here at routers Rl, R2 and R3 ) . Note that the "merging" 
5 of multicast streams at traffic replication points (such as Rl, 
R2 and R3 ) involves complex algorithms. 

RSVP and Multicasting 

RSVP may be used for multicast transmission. The RSVP PATH 
10 message will follow exactly the same path as the stream itself 
also for multicast transmission. 

Fig. 3 shows the multicasting of the PATH message. The routers 
Rl, r2, and R3 have multicasting and RSVP capabilities. 

15 

The sender periodically sends a PATH message for each data flow 
it originates. 

The RESV -message is sent by the recipients (clients 1, 2, 3, and 
2 0 4) of the stream towards the source following the exact inverse 
path of the PATH-message . The stream itself is characterized by 
a filter, so a single reservation can apply to several streams 
(e.g. several sources in a conference), i.e. a shared 
reservation. This is reflected in Fig. 4. 

25 

Fig. 4 shows that multiple reservations for a multicast stream 
can be merged. If, for example, client 3 requires a low delay 
and client 4 is prepared to cope with more delay for the same 
multicast stream, then only the largest reservation (i.e. lowest 
30 delay) will be forwarded upstream (i.e. from R3 to Rl). The same 
applies in case e.g. client 3 wants to receive the base layer 
for a specific video codec, whereas client 4 wants to receive 
the base and an additional layer. 

35 At branch points (i.e. the routers Rl, R2 , R3 ) in the 

distribution tree (to be) reserved TSPECs of the branches are 
not the same. The (to be) reserved TSPEC of a branch closer to 
the server is given by the maximum of the (to be) reserved 
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TSPECS of its direct successors (in the direction of the 
destination) . 

Differentiated Services 

Differentiated Services (DiffServ) provide mailings within IP 
5 packet leaders to allow prioritization of traffic aggregates 
(i.e. "classes" of multiple flows). DiffServ is employed to 
design a simple architectural framework for QoS that can provide 
a variety of scalable end-to-end services access multiple 
separately administered domains with requiring complex inter- 
10 provide business arrangements or complex behaviors in forwarding 
equipment . 

Bandwidth Brokers 

A Bandwidth Broker maintains information relating to SLSes that 
are defined between a DiffServ domain and its customers, where 

15 DiffServ domain denotes a region of shared trust, 

administration, provisioning, etc. Customers include local users 
as well as the adjacent networks that provide connectivity to 
other parts of e.g. the Internet. The internals of a DiffServ 
domain are not relevant to its customers, as long as the 

20 external obligations are fulfilled. The Bandwidth Broker uses 

this SLS information to configure routers in the local DiffServ 
domain (mainly the edge routers) , and to make admission control 
decisions. The Bandwidth Broker is required to keep track of QoS 
resources, make policy decisions based on SLS information, and 

25 communicate policy enforcement information to the edge devices 
within the DiffServ domain. Furthermore, the bandwidth broker 
establishes and maintains SLAs with neighbouring domains. 

The general idea is for a customer to buy from their provider a 
30 profile for higher quality service, and the provider polices 

marked traffic from the site to ensure that the profile is not 
exceeded. Where providers peer, they arrange for an aggregate 
higher-quality profile to be provided, and police each other's 
aggregate if it exceeds the profile. 

35 

In this way, policing only needs to be performed at the edges to 
a provider's network based on the assumption that within the 
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network there is sufficient capacity to cope with the amount of 
higher-quality traffic that has been sold. 


Before marked packets (DiffServ) from a data source are admitted 
5 to a Diffserv domain, the source must signal its local Bandwidth 
Broker to initiate a service reservation. The potential source 
is authenticated and subjected to local admission control 
policies. If the service reservation is admitted locally, the 
Bandwidth Broker may initiate an end-to-end reservation request 

10 along the chain of Bandwidth Brokers in the DiffServ networks to 
be traversed by the data flow. When a network-wide admission 
control decision has been made, the Bandwidth Broker will 
configure the routers in the DiffServ domain to support the 
requested service profile. The Bandwidth Broker allows 

15 separately administered DiffServ domains to manage their network 
resources independently, yet still cooperate with other domains 
to provide dynamically allocated end-to-end QoS . 

Problems 

2 0 Currently, RSVP supports limited communication/ service quality 
negotiations between servers and clients. Only the resulting 
end-to-end bandwidth and ADSPEC- information related data are 
provided to the clients. This information may be used by the 
clients to verify whether they would like to use the service 

25 with the indicated service quality characteristics. Other 

service quality characteristics, such as security, reliability, 
and actual jitter are missing and therefore not taken into 
account for the service quality negotiation. Such service 
quality characteristics are missing from the ADSPEC- information 

30 and are thus not updated on the way from the server to the 

client(s). As mentioned above, jitter information is implicitly 
included in the PATH-message, in particular in the token bucket 
parameters, but any changes thereof are not considered. 

35 Moreover, no mechanisms are currently available to efficiently 
collect information about the network domains (and clients) 
between the server(s) and client(s). 
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Since no mechanism for information collection is available, 
there is also no mechanism to handle this in a more efficient 
way in case of multicasting for one-to-many or many-to-many 
service provisioning. Further, a service quality optimization 
5 with respect to high(er) priority clients or servers is not 
available . 

Further, no mechanism exists to limit the number of wasted 
resource allocations in case of multicasting. 

10 

In order to overcome the existing problems of the prior art, the 
object of the present invention is to provide a solution for 
improving communications in a network utilizing a resource 
reservation protocol, such as the RSVP. 

15 

BRIEF DESCRIPTION OF THE INVENTION 

The basic idea of this invention is to collect information by 
extending the signaling messages in a protocol like the RSVP. 

20 Information is collected throughout the network, e.g. from all 
network domains and/or subnetworks, between servers and 
corresponding client (s). Any network component serving as a 
sender, e.g. servers, notes, routers, may use the collected 
information to check the actual status of the network, to make 

25 service distribution decisions, to make service provisioning 

decisions (e.g. links in a proxy or gateway), etc. RSVP is just 
an example for a protocol for which the present invention can be 
utilized. Therefore, the mechanisms according to the invention 
described here can be applied to similar or comparable 

30 protocols. 

The present invention optionally extends negotiation information 
between a server and respective clients which can be used by 
clients to decide on the acceptance of an overall service 
35 provisioning quality. 

In addition to an information collection for a single-client 
case, the present invention is also applicable for multi-client 
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cases wherein multicasting and/or aggregation of collected 
information is utilized. 

Moreover, a pre-reservation mechanism provided by the present 
5 invention can be implemented to prevent wasted resource 

allocations and extensive signaling in case of multicasting 
and/or to improve the quality of service for high priority 
clients . 

10 Thus, the present invention addresses an information collection 
mechanism, quality of service negotiations between a server and 
its client (s), and a pre-reservation mechanism of network 
resources, for single-client and/or multi-client applications, 
wherein in the case of a multi-client application multicasting 

15 and/or aggregation of collected information is possible. 

To achieve the underlying object, the present invention provides 
a method for improving resource reservations and allocations in 
a network operated by a given signaling message protocol, e.g. 

2 0 the RSVP. According to the given protocol, a sender signal 

including sender traffic characteristics information of a sender 
is generated and transmitted via at least one network. According 
to the invention, network traffic characteristics information is 
included into the sender signal while being transmitted to 

25 obtain an extended sender signal. The network traffic 
characteristics information is indicative of traffic 
characteristics of the network. Further, network resources are 
reserved and/or allocated in dependence of the network traffic 
characteristics information. 

30 

Furthermore, it is possible to receive the extended sender 
signal by a receiver and to generate, in response thereto, a 
receiver signal according to the given protocol including 
receiver traffic characteristics information being indicative of 
35 traffic characteristics of the receiver. Additionally, the 

network traffic characteristics information is included into the 
receiver signal to obtain an extended receiver signal. As a 
result, network resources can be reserved and/or allocated in 
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dependence • of the network traffic characteristics information 
and the receiver traffic characteristics information. 

In order to further improve service quality negotiations, it is 
5 possible to transmit the extended receiver signal to the sender, 
while updating the extended receiver signal by including actual 
network traffic characteristics information during transmission. 
As a result, network resources can be allocated in dependence of 
the updated extended receiver signal. 

10 

It is preferred to transmit the extended sender signal and/or 
the extended receiver signal and/or the updated extended 
receiver signal via at least one router and to include and/or 
update the network traffics characteristics information by 
15 including and/or updating information being indicative of 
traffic characteristics of the at least one router. 

The reservation and/or allocation of network resources can also 
be performed by the sender in dependence from the signal 
2 0 received from the at least one network, and/or the receiver in 

dependence of the received extended sender signal, and/or the at 
least one router in dependence of the received signal received 
from the network. 

25 To implement a pre-reservation and/or pre-allocation mechanism, 
reservation and/or allocation information is included into the 
sender signal according to the given protocol . The reservation 
and/or allocation information is indicative of network resources 
to be pre-reserved and/or pre-allocated. Thus, it is possible to 

30 pre-reserve and/or pre-allocate network resources in dependence 
of the reservation and/or allocation information. 

Improved network information can be obtained by including actual 
reservation and/or allocation information into the extended 
35 sender signal including the reservation and/or allocation 
information, the actual reservation and/or allocation 
information being indicative of network resources actually pre- 
reserved and/or pre-allocated. 
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In this case, it is preferred that the at least one router 
reserves and/or allocates available resources thereof in 
dependence of the reservation and/or allocation information of 
the sender and includes the actual reservation and/or allocation 
5 information corresponding to the actually pre-reserved and/or 
pre-allocated router resources. 

For a client oriented resource reservation and/or allocation, 
the receiver includes a reservation and/or allocation request 
10 into the extended receiver signal in dependence of the received 
actual reservation and/or allocation information. Here, the 
reservation and/or allocation request is indicative of network 
resources to be used for communication with the sender. 

15 As a result, it is possible to reserve and/or allocate network 
resources in dependence of the reservation and/or allocation 
request in the extended receiver signal and/or the updated 
extended receiver signal . 

20 If routers are employed, the at least one router can reserve 
and/or allocate pre-reserved and/or pre-allocated router 
resources in dependence of the reservation and/or allocation 
request in the signal transmitted from the receiver. 

2 5 As a further option, indicators being indicative of resource 

reservations and/or allocations can be included in the signals 
transmitted via the network (e.g. in the sender signal, the 
extended sender signal and/or the extended receiver signal) . 
Here, it is possible to use an indicator with respect to at 

30 least one of the network resources whether a resource 

reservation and/or resource allocation is performed for signals 
transmitted downstream to clients (e.g. (extended) sender 
signal) and/or for signals transmitted upstream to senders (e.g. 
an extended receiver signal) . Since some of the pre-reserved 

35 and/or pre-allocated resources in response to signals 

transmitted downstream to clients may be released upon a 
reception of related signals transmitted upstream to senders, 
such resources may be pre-reserved and/or pre-allocated in 
dependence of higher priority resource reservation and/or 
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allocation ■ requests . Therefore, (extended) sender signals 
including reservation and/or allocation information can include 
"minimum resource required" indicators. Resources exceeding this 
minimum resources can optionally be used with respect to 
5 reservations and/or allocations by higher priority resource 
requests. As a result, a faster connection setup for 
transmissions in the network can be obtained, since respective 
resources have already been pre-reserved and/or pre-allocated. 

10 In order to avoid unnecessary use of network resources, pre- 
reserved and/or pre-allocated network resources exceeding the 
reservation and/or allocation request of the receiver are 
released. Here, it is possible that the at least one router 
releases its pre-reserved and/or pre-allocated resources in 

15 dependence of the reservation and/or allocation request in the 
signal transmitted from the receiver. 

However, signals transmitted upstream from the receiver {e.g. 
(extended) receiver signals) can specify that all pre-reserved 
20 and/or pre-allocated resources remain reserved and/or allocated, 
or that a maximum or a minimum thereof remains reserved and/ or 
allocated. This procedure still leads to an improved quality of 
service and in particular provides a fast connection setup. 

25 Moreover, the present invention provides network system 
utilizing a given signaling message protocol for network 
resource reservations and allocations, a sender, a receiver, 
and/or at least one network for connecting the sender and the 
receiver are operated by one of the methods according to the 

30 invention. 

BRIEF DESCRIPTION OF THE FIGURES 

In the following description of preferred embodiments, it is 
35 referred to the accompanying figures wherein: 

Fig. 1 shows RSVP signaling messages and parameters thereof. 


Fig. 2 


illustrates an IP multicasting network, 
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Fig. 3 illustrates a PATH-message multicasting in a RSVP 
network. 

Fig. 4 illustrates a RESV-message inverse multicasting in the 
5 RSVP network of Fig. 3, 

Fig. 5 illustrates a network utilizing RSVP-messages extended 
according to the invention, 

10 Fig. 6 illustrates a RSVP network utilizing RESV-messages 
extended according to the invention for inverse 
multicasting, and 

Fig. 7 illustrates a pre-reservation mechanism according to 
15 the invention in a RSVP network. 


DESCRIPTION OF PREFERRED EMBODIMENTS 

20 As described above, senders, receivers, and communication means 
(routers) for routing communications between the senders and the 
receivers in a network utilize reservation protocols in order to 
set up the necessary network state and to support communications 
and associated services between the senders and receivers. One 

25 example for such a reservation protocol is the resource 

reservation protocol (RSVP) . The following embodiments are set 
forth with respect to the RSVP, however the underlying principle 
is suitable to improve other network reservation protocols, e.g. 
ST-II . 

30 

Basic embodiment 

In order to improve service quality negotiations between ser- 
vers and clients communicating via a network utilizing the RSVP, 
the signaling messages of the RSVP, namely the PATH-messages and 
35 the RESV-messages, are extended/modified to include further 

information being indicative of the actual status of the network 
and its network domains, respectively. This information is 
collected from all parts of the network used for communication 
between a server and a client. In addition to the information 
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collected for all respective network domains, it is contemplated 
that this information also includes information being indicative 
of the actual status of a server and its client (s) . 


5 On the basis of the collected information, the server, the 

client (s) and routers of the network and/or network domains are 
enabled to check the actual status of the network and/or its 
domains, to control the distribution of services provided via 
the network, to control the provisioning of network services 

10 (e.g. links to a proxy or gateway), to perform service quality 
negotiations between the server and its client (s), and to pre- 
reserve/pre-allocate communication resources of the network. 
Such a procedure can be applied to both single-client and multi- 
client applications, wherein for the latter case multicasting 

15 and/or an aggregation of the collected information is an 
additional option. 

Referring to a PATH-message of the RSVP, the traffic 
specification (TSPEC) thereof defining the traffic 

20 characteristics of a server is extended by information 

characterizing the actual traffic characteristic of the network, 
and in particular of the network domains between the server and 
its client (s) and their routers, respectively. Further, the 
TSPEC can be extended by traffic characteristics information of 

25 the client. It has to be emphasised, that the TSPEC itself is 
not modified. 


The traffic characteristics information of the network and the 
client can be provided as information directly identifying the 

30 respective traffic characteristics. As an alternative, the 

traffic characteristic information of the network and the client 
can represent variations of the actual traffic characteristics 
of the network and the client with respect to previous traffic 
characteristics thereof. Such variations can be caused by a 

35 variation of communications resources of the network or the 

client, wherein such resource variations include an increased 
and a decreased resource availability. In particular, these 
variations can relate to previous traffic characteristics of 
same network components (e.g. network domains, routers, servers. 
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clients, gateways, etc.) and/or to traffic characteristics of 
previous network components, i.e. network components located 
more upstream with respect to the direction of data 
communication . 

5 

In general, messages of the RSVP are generated by each network 
component (server, client, router) on the basis of a received 
message for forwarding the information thereof. Therefore, PATH- 
messages extended as explained above can include either above 
10 type of traffic characteristics information of the network and 
the client (s) depending on the network component (server, 
router, client) forwarding the respective PATH-message . 

Further, ADSPEC-inf ormation of the PATH-message can be extended 
15 by other communication characteristics, such as security, 

reliability, and jitter information. Comparable to the above 
traffic characteristics information, such further communication 
characteristics information are added to the ADSPEC-inf ormation 
of the server by the routers and the client (s) . 
20 Again, the ADSPEC-inf ormation itself is not changed. 

In order to access the actual communications state of the 
network and the client (s), the traffic characteristics 
information collected while forwarding the PATH-message are 

25 added to the RESV-message returned from the client (s) to the 
server. In particular, the collected traffic characteristics 
information is added to the RESV-message according to the RSVP 
to extend the TSPEC thereof. An improved communication quality 
negotiation between the server and its client (s) can be achieved 

30 by further extending the TSPEC of the RESV-message with 
information being indicative of the resulting end-to-end 
communication characteristics. Receiving such an extended RESV- 
message, the server obtains substantial information of the 
actual communications status and is enabled to adapt its 

35 communications (distribution) correspondingly, e.g. by modifying 
the distribution of provided services. 


Since the client (s) is (are) also provided with information 
being indicative of the actual communications status of the 
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network and, in addition, of the server, the respective RESV- 
message can be generated considering the received communications 
status information. If, for example, a client determines that 
the over-all communication quality (quality of service) is not 
5 acceptable, the RESV-message will not be returned and thus no 
resource allocation for the respective communication path 
between the client and the server is performed. 


Further, a service reject by the client can include information 
10 indicative of reasons for the service reject. In response, the 
server can use such information for e.g. traffic engineering 
and/or network planning purposes. 

Moreover, as a further option, the RSPEC-inf ormation and/or the 
15 FilterSPEC-inf ormation of the RESV-message communicated to the 
server can be extended by further information being indicative 
of the communication (quality) characteristics in a manner 
comparable to the ADSPEC-inf ormation of the PATH-message . 

2 0 Traffic characteristics information collection for a network 
domain serving a single client 

For the purpose of simplicity, the embodiment shown in Fig. 5 
utilizes RSVP-messages only including respective TSPEC- 
inf ormation . 

25 

As shown in Fig. 5, a communication path between a server and a 
client is routed via routers Rl and R2 constituing the network 
domain serving the client. The server generates a PATH-message 
according to the RSVP and transmits the same to the router Rl . 
30 In order to indicate the type of mechanism, which is used or 
which is to be used, the PATH-message can be extended 
accordingly . 

In response thereto, the router Rl processes the received PATH- 
35 message according to the RSVP. Assuiming this processing results 
in a validity for the received PATH-message, the router Rl 
generates a conventional PATH-message including, according to 
the RSVP, the traffic characteristics provided by the server and 
updated routing information. Here it is pointed out, that this 
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conventional PATH-message does not include any information 
representing the actual traffic characteristics of the network, 
so far. 

5 Further, the router Rl generates information which represent its 
actual traffic characteristics. Such information can include the 
maximal /average peak rate of flow, the available bandwidth, the 
actual delay, the actual jitter, the actual security level for 
data communications, actual allocated resources, available 
10 buffer space, and the like. This traffic characteristics 

information of the router Rl is added to its conventional PATH- 
message such said a message PATH' is obtained. 

The PATH ' -message is transmitted to the router R2 which 
15 generates, in response thereto, a message PATH" ' in a manner 
comparable to the generation of the PATH ' -message . 

The PATH" '-message transmitted from the router R2 is received by 
the client. In case, the processing of the PATH '' -message by the 
2 0 client is indicative of a communication/service quality being 

not acceptable for client, the client generates no RESV-message . 

In case, the PATH' '-message is indicative of a 

communications /service quality being acceptable for the client, 
2 5 the client generates a RESV* -message . The RESV*-message comprises 
a conventional RESV-message according to the RSVP and, further, 
the collected traffic characteristics information. In addition, 
the RESV* -mess age can include information representing the end- 
to-end characteristics calculated for the communications between 
30 the server and the client performed so far. 

As a further option, it is possible that the RESV* ' -message 
received by the router R2 is extended by its actual traffic 
characteristics information and transferred as a RESV* ' -message 
35 to the router Rl . Comparable, the RESV* ' -message is extended by 
the router Rl and transferred as a message RESV*' '-message to 
the server. 
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On the basis of the received RESV* ' '-message, the server is 
enabled to access the actual coiranunications status of the 
network domain serving the client. It is pointed out that this 
collection of traffic characteristics information can be 
5 performed when a communications /service is to be provided to the 
client, or can be just used to collect such information without 
providing communications/services. In order to inform the 
routers Rl , R2 and/or the client whether the collection of 
traffic characteristics information is performed prior to the 
10 provision of communications/services or just for an assessment 
of the actual network status, the server can transmit a 
respective information, e.g. an indicator. 


Multicasting aggregation 
51 15 In order to provide communications /services between one or 
% several servers and several clients, the above described 

si multicasting is used for the message distribution. For the 

P collection of traffic characteristics information, the PATH- 

messages from the server (s) and the routers of the (respective) 
5 2 0 network domain (s) are extended as set forth above for the single 

client case. Therefore, the respective extended PATH -messages 
ijj from the server to the clients 1, 2, 3 and 4 are not shown in 

S Fig 6 . 

25 As explained above, the RESV-message received by a server for a 
conventional RSVP multicasting comprises aggregated RESV- 
messages from the respective clients. This aggregation serves to 
merge multiple reservations from several clients for a multicast 
stream. 

30 

In order to obtain a RESV*-message (i.e. a RESV-message extended 
by traffic characteristics information) , an aggregation step is 
performed to provide the traffic characteristics information of 
the network domains serving the clients 1, 2, 3 and 4 and the 
35 resulting communications /service quality for each end-to-end 
(server-client) connection. 


Assuming that the traffic characteristics of the connections 
(networks) between the router R2 and the client 1, and the 
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router R2 and the client 2 are the same, information being 
indicative of these traffic characteristics only need to be 
communicated to the server once. As a result, the RESV*i 2 ' - 
message communicated from the router R2 to the router Rl only 
5 contains traffic characteristics information of the client 1 
provided by the RESV\-message , the traffic characteristics 
information of the client 2 provided by the RESV*2-message and, 
just once, traffic characteristics information related to the 
network domain comprising the router R2 , and the clients 1 and 
10 2 . 

In case the traffic characteristics of the networks between the 
router R2 and the client 1, and the router R2 and the client 2 
are not the same, or in case the clients 1 and 2 are not 

15 comprised by the same network domain, the router R2 must 

determine the overlap of the respective traffic characteristics 
information and aggregate the traffic characteristics 
information accordingly. As an alternative, router R2 can also 
just select e.g. the traffic characteristics which are received 

20 first. 

This aggregation step is accordingly performed with respect to 
the router R3 and the router Rl, respectively, wherein the 
transmitted RESV* ' 3_4-message and the RESV* \_2,3, 4~^®^^^5^ 
25 extended by the respective traffic characteristics information 
of the network domains including routers Rl and R3 . 

As a result, the RESV* ' ' 2 3 ^-message received by the server can 
only comprise, beside the traffic characteristics information of 
30 the clients 1, 2, 3 and 4 and the routers Rl, R2 and R3 , traffic 
characteristics information of three network domains. 

As an option compared to the above described network -wide 
aggregation for network domains, it is contemplated to perform a 
35 network domain related aggregation. Here, aggregated traffic 

characteristic information per network domain is included in the 
messages transmitted in direction to the server. As a result, 
with reference to Fig. 5, the server receives a message 
including the traffic characteristics information of the RESV'^- 
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and RESV*2-messages, of the RESV*3- and RESV*4 -mess age s , and the 
RESV*i,2- and RESV*3,4-messages . 

Pre-reservation of network resources 
5 As explained above, RSVP resource reservations for a network or 
network domains are obtained by transmitting a respective 
ADSPEC-information comprised by a PATH-message . The ADSPEC- 
information is received by the network or the network domains, 
and especially the routers thereof, to determine the level of 

10 resource reservation required for a desired server-client 
communication/ service quality. For allocating the reserved 
resources, the routers utilize a RESV-message transmitted from 
the client to allocate the necessary resources. In particular, 
RSVP-routers along the upstream path (i.e. in a communication 

15 direction towards a server) receiving RESV-message (s) utilize an 
admission control to authenticate respective resource request 
and allocate necessary resources. If a router can not provide 
the requested resources (e.g. due to a lack of resources or 
authorization failures) , the router returns an error message 

2 0 back to the client. If the resource request (s) can be satisfied, 
the respective router sends the respective RESV-message ( s ) 
upstream to the next router. 


For example in the case of a multicasting RSVP system, the 
25 following procedure of pre-reserving resources prevents 

unnecessary resource reservations downstream from the server to 
the client and that e.g. a router close to the server can not 
provide the required resources for allocation resulting in error 
messages sent to the client. A particular effect decreasing the 
30 communication/ service quality (e.g. communication transmission 
time) of such error messages sent back to the client is the 
release of allocated resources previously allocated by routers 
arranged between the error message sending router and the 
client. Further, correct and proper processing of such error 
35 messages generated by different clients is complicated. 


The pre-reservation mechanism shown in Fig. 7 is enabled by the 
modification of the RSVP as described above. Beside the 
extension of the RSVP-messages transmitted from the server and 
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the clients as detailed above, the PATH-message of the server is 
extended by a pre-reservation request. In Fig. 7, this extension 
is indicated by the index "°" . The pre-reservation request of 
the server specifies a resource type and the extend thereof to 
5 be reserved. 

Comparable thereto, the client extends the extended RESV*- 
message generated as explained above by a allocation request. 
Here, the index "°" is indicative of the allocation request. 

10 

Referring to the example shown in Fig. 7, the server requests 12 
units of the specified resource type. Upon receiving the PATH°- 
message, the router Rl determines whether he can satisfy this 
request. Since the router Rl is able to provide the requested 
15 resources, the router Rl pre-reserves 12 units. 

The router Rl generates a PATH° ' -message extended by the above 
traffic characteristics information and the pre-reservation 
request. Although router R2 can only provide 8 units, which are 
20 reserved, the PATH°' '-message of router R2 is generated and 

transmitted to the router R3 . In contrast thereto, according to 
a conventional RSVP system, an error message would be returned 
to a client in response to a RESV-message thereof to indicate 
that a resource request can not be satisfied. 

25 

The router R3 is able to provide 4 units of the requested 
resource and reserved the same. Again, no error message is 
returned to the server, but a PATH" '' -message is communicated to 
the client. 

30 

Therefore, the client gets a communication/ service resource 
request which is agreed and confirmed by all routers Rl , R2 and 
R3 between the server and the client. 

35 Upon confirmation of the received resource request, the client 
generates a RESV*°-message extended as the explained above and 
including an allocation request. Since the received resource 
request indicates that 4 units of the requested resource type 
can be provided for the overall communications connection 
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between the server and the client, the allocation request 
generated by the client indicates that four units of the 
requested resource type are needed and should be allocated by 
the routers Rl , R2 and R3 . 

5 

While transmitting the RESV*°--, RESV*°''- and RESV*° ■■" -messages , 
which include the above explained extensions by the routers Rl, 
R2 and R3 and the allocation request of the client, each of the 
routers Rl , R2 and R3 allocate 4 units of the requested resource 
10 type and release the previously reserved units actually not 
needed. 


Further, messages transmitted upstream from the client and 
routers Rl, R2 , and R3 (e.g. RESV*°'-, RESV'°"-, and RESV*°"'- 
15 messages) can include information specifying that all pre- 

reserved and/or pre-allocated resources remain reserved and/or 
allocated, or that a maximum or minimum pre-reserved and/or pre- 
allocated resources remain reserved and/or allocated. This 
approach still results in an improved QoS . 

20 

The pre-reservation/pre-allocation mechanism can be used to 
ensure that clients and/or servers having a high(er) priority 
will be provided with required resources. 

25 Additionally, it is contemplated that the server can extend his 
RSVP-message by information (e.g. in form of an indicator) 
representing an upper and/ lower limit of resources to be re- 
reserved (maximum/minimum resource reservation indicator) . 

30 Since some of the pre-reserved resources in response to a PATH°- 
message may be released upon the reception of the respective 
RESV*°-message , such resources could be partly used by an 
allocation request having a higher priority. As set forth above, 
an indicator in each router is used to specify whether a 

35 resource reservation is an actual resource allocation in 

response to a RESV-message or a pre-reservation in response to a 
PATH-message . To specify the amount of pre-reserved resources 
which can be used to satisfy a higher priority resource 
allocation, the above minimum resource reservation indicator can 
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be used. The amount of resources above the limit defined by this 
indicator can be optionally used to fulfill a higher priority 
resource allocation request related to a different PATH-request . 
As a result, a communication connection related to the higher 
5 priority resource allocation request can be setup faster since 
these resources have already been reserved and no separate 
reservation is required. 


Comparable to the maximum/minimum indicators of the PATH°- 
10 message, the RESV*°-message can specify a minimum and/or a 

maximum of resources (types) to be allocated. For example, the 
RESV*°-message specifies said all routers should provide the same 
minimum bandwidth, such that all bandwidth related resources of 
the routers unnecessarily reserved are released. 

15 

Especially the utilization of minimum resource indicators for 
the PATH°- and RESV*°-messages guaranties said servers and/or 
clients having a higher priority are provided the required 
resources, since related higher priority resource requests can 
20 be fulfilled and are not blocked by a reservation of resources. 


